\chapter{The Group Process}

% * (5 pages) Discuss how the group worked; what went well and what didn't work.
% * Have you learned anything about group work - would you change anything about
%   the way you worked if you had to start again.
% * What methods were employed to assist the group process?

% Introduction to the group
When we set out to begin our group project we knew from the very start that in
order to be successful we would have to work as a team. Our past experiences of
group work had highlighted the problems that arise when individual group
members work on their own, with little to no interaction with other group
members. On attendance of the group away day we all shared a similar vision
of the group we wished to form, thus making the group selection a lot easier as
we were already familiar with one another and confident of each other's ability
to work as part of a team.

The formation of the group was a merging of two sub-groups from the second year
group projects, the one sub-group consisting of Ant, Tom and Jamie, and the
other consisting of Stephen and Richard. This added a sense of comfort to the
initial formation as we had at least one other person in the group who we were
well acquainted with and worked well with.

We decided early on that we did not need to appoint a group leader as we were
all confident of each other's level of motivation and felt that if anyone were
to fulfil the role of a group leader that it would happen naturally and not be
a forced decision. This led to a sense of equality in the group where everyone
could voice their own opinion and decisions were made by the entire group
rather than one individual.

\section{Methods Employed}
% Brainstorming
Throughout the development lifecycle we employed a number of group techniques
to assist us in successfully completing our project. One of these techniques
included the utilisation of brainstorming which was integral to the planning
stages of the project. For our first few meetings our main agenda was to come
up with ideas for a game. These meetings consisted of all group members coming
up with ideas and presenting them to the rest of the group, prompting other
group members to build upon the idea. This took place over a number of meetings
as we built upon our ideas, considering all aspects such as the game rules,
content creation and difficulty in implementing the idea. We eventually narrowed
them down until we had two final ideas that we were happy to pitch to the panel.

We continued to exercise our brainstorming techniques throughout many stages of
the development lifecycle as it assisted us not only in coming up with ideas,
but also problem solving. We decided early on that we would work closely with
one another and do the majority of the group work in each other's company
inside the pod room. This was extremely beneficial if any of us encountered a
problem during implementation as we were always there to assist one another
with any problems. Due to the close proximity of working with one another we
were able to explore other group techniques such as the `Jigsaw' technique
where we would merge our areas of expertise when needed to overcome any
problems. This technique was good practice when a group member approached
an area of the project that they had little knowledge of, as they could seek
the help of another group member who possessed that knowledge.

% The Jigsaw technique
The `Jigsaw' technique is a commonly used group technique which involves a large
task such as a project being divided in to a number of smaller tasks. These
tasks are assigned to individuals within the group where each are held
accountable for completing their own task. In order to be successful in
completing the project, the individuals must merge their completed work with one
another to form the complete product. An example of the `Jigsaw' technique being
put in to practise could be described by the integration of the menu system with
the main game, where Richard had to work closely with Jamie to get the main menu
to create a new game session so that the game could be played via the main menu.
Jamie had implemented \verb"GameSession" class, whilst Richard had implemented
the \verb"MenuMain" class, with neither knowing much about each other's
implementation. This gap in knowledge was bridged by the two combining their
areas of expertise to compose a solution. This kind of occurrence was very
frequent. Working closely together as a team over the duration of the project
meant that we rarely wasted time working outside the bounds of our respective
areas. If when working on a particular feature we had to interact with some
other part of the game, it was much quicker just to ask the person responsible
for that area to explain, or just to address the issue, rather than spending
time trying to figure out how it works. This resulted in a highly productive
environment where problems were overcome a great deal quicker than if one person
were to tackle the problem entirely by themselves.

% Pair programming - Toner, brilliant sentance!
% During the employment of this technique there would often be two people working
% on one problem. 
We did not explicitly adopt pair programming techniques into our project, but on
many occasions it was beneficial for us to work as pairs. One such point was at
the end of the project where parts of code, written by different members had to
be integrated together. To do this one person would fulfil a `driver' role and
type, whilst the other fulfils the `observer' role by reviewing the code and
informing the driver of any mistakes or improvements they can make to the code.
A critical element of the paired process is the discussion of ideas from either
programmer as this was vital to the integration of each other's code. We often
switched roles when working on the larger tasks, especially when the task
delved in to one person's area of expertise, where it was probably best for
them to fulfil the driver role. We had all gained experience of pair
programming from the Software Engineering units taught and so we were all
comfortable and confident of our abilities to program as a pair.

We believe this method was vital to our success in merging our different areas
of the project together and we all accomplished a far greater understanding
of the project as a whole by working closely with others who were working on
a component of the project that we had little knowledge of. In addition to this,
it made the work process a lot more enjoyable as it made the work environment
a lot more sociable than everyone just getting on with their own parts of the
project.

% Extreme Programming
We drew a lot of inspiration from the Extreme Programming methodology, exploring
many of the principles such as the application of incremental changes to the
project plan. This encouraged individuals within the group to continue thinking
about additions to the game to improve it, as we would try to fit it in to the
project plan if we agreed on it's worth.

In terms of our time management we did not explicitly state that we would stick
to a timetable of working within the confines of the pod room. However we all
got in to the habit of working from 9am to 5pm every weekday, excusing time for
lectures and lunch breaks. When it came to meeting our personal deadlines for
the project we even worked through the weekends. However we abided by the
concept of sustainable pace, ensuring that no one was overworking themselves.
This applied greatly to the consideration of each group member's individual
deadlines outside of the group project in their other units. We did not expect
anyone to jeopardise their individual work and excused them from their group
duties when they felt they needed to get on with their individual work for a
few days.

% Meetings
Despite working so closely with one another, we still found it highly beneficial
to hold regular group meetings so we could take a break from the code and focus
a bit more on the practical and design-based issues. These meetings were also
helpful in informing the rest of the group of everyone's position in relation
to the deadlines set for them and giving everyone a good idea of what stage the
project was at.

The meetings also played host to where we made the majority of our decisions in
relation to project planning and ideas for the game. When it came to making a
decision we ensured that everyone had pitched their own ideas and discussed
them in enough detail so that we could make a fully informed decision as a
group. This would normally involve a majority vote or even a merging of two or
more ideas to keep everyone in the group satisfied. This democratic approach to
decision making rarely resulted in conflict, but there were occasions when
we had trouble agreeing on something as some individuals truly believed in their
ideas. However we overcame the majority of these disagreements to form a
decision that was best for the group as a whole.

% External Advisors
At the start of the project we had been assigned an external advisor called
David Oziem who we met with on a number of occasions. Whenever we had made any
significant progress with our game we contacted David via e-mail and organised
a time and date to meet up and show him what we have accomplished. We used
these meetings to discuss what we could do to improve the game and discuss
what our future plans were. David was extremely helpful in highlighting some
areas that we had overlooked as developers, such as the lack of fun and
objectivity in our demo release. We had been far too focused on simply getting
the game to play and completely disregarded until this point such as power-ups
and interactive items to make the game that little bit more interesting and fun.

After one meeting we had discussed that our game did not have particularly
complicated graphics and we were worried that this might have an impact on our
mark. To obtain some advice on the issue, we met with Colin Dalton a graphical
specialist in the Computer Science department, to give us his opinion on the graphics
and how he felt it might affect our mark. The feedback received from all parties
assisted us in realising that in order to create a successful game we would need
to look to people who were not a part of our group and could view it
from a non-developers perspective to identify what would make the game enjoyable
to play. This realisation introduced a new method to our group process where we
would regularly ask our friends and peers to test out the game and simply give
their feedback to what they think would improve the user experience.

% Communication during absence
With such an established sense of communication in the group when working
through term time, it was important that we maintained that level of
communication during any holidays or periods of absence for any group members.
We accomplished this through a number of mediums including e-mail, phones and a
communal log we kept of our progress on Google Documents. The regular updates
and communication were vital to the success of the group during the Easter
holidays, where it was rare to have all of the group present at one time.
E-mails would be sent out regularly informing the whole group of the current
progress. For a more detailed account of what had been accomplished, group
members could check the log document where everyone kept an account of what they
had accomplished or any problems that they had encountered. Keeping this turned
out to be beneficial in a number of ways as it also offered a reference to our
contributions when it came to writing the report and recounting what we had each
contributed to the project.

\section{Problems}

Despite the agile nature of our work process we encountered very few problems
throughout our time of working with one another. This was surprising as the
methodology of agile development is well-documented for conflict to arise over
personal programming techniques and differences in a person's approach to
problem solving. We believe that we successfully avoided such hostility due to a
lack of conflicting personalities in the group and absence of any ego concerning
our approach to development. This isn't to say that we did not disagree at
times, as we occasionally encountered problems in decision making especially
when some individuals had opposing ideas that they truly believed were better
than the other idea. This would make the process a lot more difficult as we did
not want to simply dismiss one of the ideas if the group member believed so
strongly in it. Whenever a disagreement like this emerged we would do our best
as a group to incorporate the two ideas together or choose whatever we believed
would be better for the group in the long run. This seemed to work for us as
any dismissal in ideas were well justified and no hard feelings were evident
as a result of the decision.

% Pre-Christmas complacency
The dynamics of the group were unaffected by competition for status and
influence, which we believe was a by-product of not appointing anyone as group
leader. However we did encounter a number of other problems unrelated to
personal conflict, one of these being the lack of direction in the first few
weeks of the project. Once we had been informed which game we were to proceed
with, the regular meetings we planned began to dwindle due to the pressures of
lectures and coursework in the first term. This left us not knowing where to
start on a project of such magnitude. We spent the majority of the meetings we
did have discussing the gameplay elements and attempting to pin down exactly
what we wanted to achieve with the game. However this was the format of many of
the meetings and we never really seemed to make any progress or seem any closer
to the stages of implementation.

As time passed leading up to the Christmas holidays the meetings became less
frequent and we found ourselves enveloped in our individual work with little
time or thought for the group project. We decided towards the end of the term
that we really needed to get on with the project and that we had wasted far more
than enough time already. We established that we would all stay for an extra
week once the Christmas holidays began and finally begin the final stages of
planning and the beginning of the implementation stages of the project. The week
was highly successful and we found ourselves in a position where we could
actually begin properly programming upon our return in the new year.
Nevertheless our achievements did not excuse the fact that we wasted valuable
time that we could have used to be in an even better position by the Christmas
holidays. This was undoubtedly the fault of all group members and there was no
direct blame for our complacency, knowing we would have to work a little bit
harder in the later months to make up for lost time.

% Spontaneity issues
Another common problem that we faced included the spontaneity of some group
members; where they would begin working on something without consulting other
members of the group. This sometimes resulted in unnecessary work being carried
out as it was rejected at a later stage when presented to the rest of the group.
This rarely resulted in conflict as the reasons for the dismissal of the
contribution were always justified, and the decision to do so was normally
unanimous. However it still meant that valuable time was lost when the group
member could have been working on something of worth for the final project. This
could have been avoided by a heightened awareness of what everyone is working on
and ensuring that no one began a new task without consulting the rest of the
group.

% Decision making
This problem shared much in common with a problem we had concerning the lack
of decision making in terms of the less technical aspects of the game. This
included the theme of the game as well as the design of the menus and user
interface. A lot of time was wasted producing multiple menu designs without
having even decided on the theme and look of the game. Once we had made the
final decision to give the game a futuristic look and feel, the menus required
a complete overhaul to remain in-keeping with the theme of the game. This was
highly time consuming and could have been avoided had we established exactly
what we wanted at an earlier stage.

Nevertheless we seemed to overcome both of these problems over time as
communication strengthened between the group. Once we had identified these
problems we made every effort to avoid them happening again and ensured that
everyone had a clear idea of what was expected of them.

\section{Reflection}

In reflection we believe that we worked very well as a group and have learnt a great
deal about the finer points of team work. We realised that the key to our success was
the constant good communication and group solidarity. Without the help of
one another we would have taken much longer to produce the work expected of us.
Although it might be considered inviting disaster to let a group take it's natural
course without any leadership, we proved that sometimes a group does not need
an appointed leader to be successful. We were each thankful to have a group of
fully-focused individuals who could all represent themselves and form decisions
as a whole rather than relying on one individual to keep everything together.

% Importance of pair programming
During our time as a group we have also discovered how effective employing pair
programming techniques can be. Pair programming was vital to successfully
merging different areas of the game together; it would have been incredibly
difficult for one person to learn what another person's code was doing and then
atempt to merge it with their own. A great deal of time and effort was saved by
employing this technique and we would each use it again in future projects.

% What we would do next time
If we were to start the project again we would probably choose to work in the
same way, but incorporate a few more established time management methods in to
our plan. This would include using our time wisely from the very start and
beginning as soon as possible to avoid losing valuable time. We would continue
to work as a group at all times and discourage group members from working by
themselves. This would ensure that there was constant communication between all
group members. We would also ensure that we informed one another of our
progress regularly so that we avoid the mistake of wasting time on unnecessary
work. Despite the minor problems that we faced during the development
lifecycle, there was nothing that highlighted any major flaws in our methods of
group work and we are all satisfied in the way in which we worked with one
another.
